Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0131/434.txt

Text File | 1997-04-16 | 26KB | 616 lines

Info-Atari16 Digest         Fri, 16 Aug 91       Volume 91 : Issue 434

Today's Topics:
                        Atari CD-ROM? (4 msgs)
                    Clearing space on a hard disk
                        Dialog Boxes (2 msgs)
                   Help for an old, handicapped ST?
                            Is BART down?
                  Puting a pixel to screen (3 msgs)
                             Spectre GCR
                               Turbo St
                    Using a big hard disk (3 msgs)

Welcome to the Info-Atari16 Digest.  The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out.  Please send notifications about broken digests or bogus messages
to [e-mail].

Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
instead of the moderators are likely to be lost or ignored.

If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------

Date: 12 Aug 91 08:56:35 GMT
From: uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail] (Jack W. Wine)
Subject: Atari CD-ROM?
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Sheppard) writes:
>CD-I players are based on the 68340 chip, a derivative of the 68020, and
>CD-RTOS, a specialized version of OS-9.  Since the STE (or TT) can both
>run OS-9, it wouldn't be too much of a stretch for either machine to be
>CD-I compatible, though it might take some additional hardware (on a VME
>card?) to support the full motion video.

I hope more information can be given on CD-RTOS.  A Magnavox brochure
describes it as providing a user shell with the following functions:

        o Auto-start CD-I
        o System entry
        o Load Application
        o Display Time/Date
        o CD-DA auto-start/repeat/shuffle
        o Info (calls up function info screen)
        o Dim screen

Mating Microware's CD-RTOS with Motorola's M68340 super-muscular micro-
controller sounds awesomely devastating.   Supposedly, one series of CD-I
machines will use a Signetics 68070 which is something like a 68K with
integrated DMA, timer and I/O support.  I don't know much about the M68340,
but found this info about a close relation, the M68332:

       "The 68332 is the first member of Motorola's revolutionary new
        family of highly integrated, high-performance 32-bit devices
        designed to meet the ever-increasing demands of embedded-control
        functions.

        The 68332 is the world's most powerful microcontroller with a
        high-performance 32-bit CPU core.  The CPU is surrounded by
        'smart' peripherals, including a powerful RISC-like TPU (Time
        Processor Unit), to reduce CPU overhead.  The result is the
        ultimate in system performance.

        Just as the human brain has two hemispheres, one for sequential
        logical operations and one for simultaneous creative operations,
        the 332's CPU and TPU perform as two powerful CPUs on one chip:
        one to process numbers and one to process time.  For many appli-
        cations, our two-CPU approach is more powerful than any feasible
        single-CPU alternative.

        The 68332 is truly the best of both the microcontroller and micro-
        processor worlds.  Its high degree of system integration eases
        system design and slashes the total chip count.

        Functional modules of the 68332 include:

          o A 32-bit CPU fully compatible with the 68K Family
            software.

          o A RISC-like high performance TPU which processes 16
            channels of time-based event functions independent
            of CPU intervention.

          o The TPU has a prioritized scheduler, RAM and ROM
            to help manage sophisticated time-related control
            functions.

          o A Queued Serial Module containing two separate serial
            interfaces, one synchronous (SPI) and one asynchronous
            (SCI), for easy attachment of specialized, off-chip
            peripherals without using the CPU as an interface.

          o 2KB of fast static RAM with standby capability for
            low-power applications and battery backed-up operation.

          o A System Integration Module (SIM) containing programmable
            chip selects, system clock, periodic interrupt, test/emul-
            ation, and system protection features.

        Additional members of the 300 Family will be introduced that will
        provide a variety of peripherals and discrete logic functions com-
        bined with a powerful 32-bit CPU.  Available modules will include
        ROM, DMA, A/D, EEPROM and many others."

The M68340 would probably have the integrated DMA and maybe the ROM and
EEPROM.  Its clock speed isn't known, but probably is 16-20 Mhz.

Jack

------------------------------

Date: 12 Aug 91 09:13:30 GMT
From: uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail] (Jack W. Wine)
Subject: Atari CD-ROM?
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert Luneski)
 writes:
>Before you hold your breath for the introduction of CD-I, consider that
>Phillips has been promising it's imminent introduction for the last three
>years.  Sound like any company we know?  Nah.... :-)

There is every indication that consumer CD-I systems will be available in
the coming months.   Sony sponsors a segment on a daily radio show which
promotes and provides information about CD devices.  For the entire week
last week, the features of CD-I were announced.  The announcer didn't use
generalities, but provided the actual specs for a typical system.  Some
of the announced details of the broad range of video mode colors: DYUV 16
million, RGB 32,768, CLUT8 256, CLUT7/RL7 128 and RL3 with 8.  The video
resolution is 384/768 (horizontal), 240/480 (vertical).

Philips/Magnavox recently started to provide brochures to anyone interested;
just contact them at: One Philips Drive, PO BOX 14810, Knoxville. TN 37914.
Phone number is [phone].

In Europe: Philips Interactive Media Systems, PO BOX 80002, 5600 JB Eindhoven
The Netherlands.

Ask for the CD-I 910 and 602 systems' brochures.

Jack

------------------------------

Date: 12 Aug 91 09:43:35 GMT
From: uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail] (Jack W. Wine)
Subject: Atari CD-ROM?
To: [e-mail]

In article <[e-mail]> [e-mail] (Graham
 Higgins) writes:
>
>_Both_ UK ST mags (STUser & STFormat) are reporting AtariUK's intentions to
>make available a CD-I peripheral for the ST/TT (one mag reports the spec). They
>warn the drooling reader that purchase availability is likely to be
>early/mid-92 with a guestimated price tag of 400 pounds sterling.
>
>Let's hope that Atari's marketing management make a better job of CD-I than
>they did with CD-ROM.

That sounds like a good development!  In the US, the actual price would be
around $500, I think, because hardware seems to be cheaper here.  That would
put the Atari CD-I in the range of regular CD-ROM drives, so instead of being
limited to a niche market, it could carve out something much bigger.

Another Atari product mentioned in the online mags was a super-graphics engine
based on a RISC processor that connected to the ST DMA port.  It was supposed
to be designed in England, so I hope some UK net readers can keep everyone
abrest of its development and availability.

Thanks,
Jack

------------------------------

Date: 12 Aug 91 11:54:53 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wupost!psuvax1!psuvm
 !dearn!dmswwu1c![e-mail]
Subject: Atari CD-ROM?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Neil Forsyth) says:
>In the same purile rag, there is mention that Atari are to provide TOS 2.x
>as 512K ROM upgrade for all machines including STFM's. They do not say who
>their 'sources' are but it wasn't Atari. I view this piece of reporting as
>pure nonsense since we know that the Mega STE ROM is 256K and will take
>TOS 2.x (Lars has done it!) but the STFM has only 192K of ROM address space.
>Upgrading an STFM would involve some serious hacking to the machine, including
>a new GLUE chip, and I doubt that Atari are going to do that.
>
I know of at least two groups of german developers, who have this thing up
and running. I think we will here more about that after the Atari fair in
Duesseldorf (Aug 23-25).
___________________________ cut here _____________________________________
Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
fast eMail: [e-mail],    slow: [e-mail] (++49 251 77216)
____________________ correct me if I'm wrong _____________________________

------------------------------

Date: 12 Aug 91 10:37:11 GMT
From: waikato.ac.nz!comp.vuw.ac.nz!actrix![e-mail] (Alex
 Valdez)
Subject: Clearing space on a hard disk
To: [e-mail]

Why not just backup one's hard disk (by files, not an image copy), do
a low-level format, and restore? And you get a clean unfragmented
drive in the process as well.

--
================================Alex Valdez=============================
"Alas sais na naman, oras ng pagdidili-dili...
 Isaisip ang mabuti, ang masama'y iwaksi..."

------------------------------

Date: 12 Aug 91 10:46:08 GMT
From: waikato.ac.nz!comp.vuw.ac.nz!actrix![e-mail] (Alex
 Valdez)
Subject: Dialog Boxes
To: [e-mail]

In article <[e-mail]> [e-mail] (Jim Omura)
 writes:
>
>      One thing I'm curious about right now:  Is there any reason
> to open the "physical workstation" if you aren't going to be using
> GDOS calls?  I haven't found anything in the Lattice C docs telling
> me when and where you use 'v_opnwk()' as opposed to 'v_opnvwk()'
> except that you can *only* use 'v_opnwk()' if GDOS is present.
> But everything I've done (except the 'vro_cpyfm() call) has been
> working so far without my using 'v_opnwk()' at all.
>
>
>
> --
> Jim Omura, 2A King George's Drive, Toronto, [phone]
> lsuc!jimomura
> Byte Information eXchange: jimomura

You cannot use v_opnwk() for the screen, as it has already been done
by AES itself. With GDOS present, you can (and must) use v_opnwk() to
open other physical devices such as a printer.
--
================================Alex Valdez=============================
"Alas sais na naman, oras ng pagdidili-dili...
 Isaisip ang mabuti, ang masama'y iwaksi..."

------------------------------

Date: 12 Aug 91 11:55:16 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!wupost!psuvax1!p
 suvm!dearn!dmswwu1c![e-mail]
Subject: Dialog Boxes
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jim Omura)
says:
>     So that would mean that "v_opnwk()" in Lattice C is an entirely
>bogus command!  Neato! :-)
>
And wrong. Of course there are other things than screen workstations. Think
about printers, metafile drivers, postscript drivers or plotter drivers.

>Conclusion #1:  We need some new books put out on GEM/TOS programming.
>Hopefully, some of those books will be the manuals that come with
>these compilers.
>
>Conclusion #2:  (Ahem.  I have another conclusion but I think I will
>not currently state it in public. :-)
>
>Supposition:  "v_opnwk()" is probably necessary for some GDOS commands.
>Probably I'll find this out if I ever actually use a GDOS related command.
>That's fair enough.  In the mean time, I won't worry about it and I
>won't use it.
>--
>Jim Omura, 2A King George's Drive, Toronto, [phone]
>lsuc!jimomura
>Byte Information eXchange: jimomura

___________________________ cut here _____________________________________
Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
fast eMail: [e-mail],    slow: [e-mail] (++49 251 77216)
____________________ correct me if I'm wrong _____________________________

------------------------------

Date: 12 Aug 91 02:50:06 GMT
From: comp.vuw.ac.nz!actrix![e-mail] (Roger Sheppard)
Subject: Help for an old, handicapped ST?
To: [e-mail]

In article <[e-mail]> [e-mail] (John R. Bane) writes:
> My ancient and revered 520 has a problem.  Its serial port has partially
> died; it can send but not receive characters.  To give you an idea of
> how old this machine is, it started out with a single-sided external floppy.
> It now has an external double-sided floppy, an 80 meg hard drive, and a
> 1/2.5/4 meg RAM board from Tech Specialties (currently at 2.5 meg).
> The serial port is important to me, as it's how I do my backups.
>
> I'm trying to find the cheapest way of fixing this mess.  The options I've
> thought of are:
>

> Anybody else ever have a serial port hardware problem? Did you solve it?
> Anyone have a machine to sell?
>
> Bob Bane ([e-mail])
> --
> Internet: [e-mail]
> UUCP:...uunet!mimsy.umd.edu!bane

Just replace the RS232 receve IC. MC1489A/UA1489A, this is IC No. U13
in the old ST's.

They can some times get damaged with Modems that don't have a earth,
and you plug them in with the power on..!!

I know I used to work for a Big banking net work, the bigest in NZ.
and we used to replace at one time some 2 IC's a week..
--
***  Roger W. Sheppard             [e-mail]  ***
***  85 Donovan Rd           *     GEnie.  R.SHEPPARD5               ***
***  Kapiti                *  *    At least I don't Flicker,         ***
***  New Zealand..          *      not like a dying light globe      ***

------------------------------

Date: 12 Aug 91 10:01:57 GMT
From:
 pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!nntpd.lkg.dec.com!aidev.enet.
 dec.com![e-mail] (John Miskinis)
Subject: Is BART down?
To: [e-mail]

Has anyone been able to download from Bart recently?  I'm sending
requests to [e-mail] but haven't got anything
back...

Actually, to be more specific I tried getting spcpics/robotarm.pic
and spcpics/trontank.spc...

_John_

------------------------------

Date: 11 Aug 91 07:03:00 GMT
From: mcsun!news.funet.fi!funic!nic.funet.fi![e-mail] (Kimmo
 Lahtinen)
Subject: Puting a pixel to screen
To: [e-mail]

I want to know what is now the "official" way to put a pixel to screen.
I have read form this group that Line-A is not a good idea, but I did
not find any simple pixel routines from VDI.

I hope it is not too slow.
--
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Kimmo Lahtinen                      E-Mail : [e-mail] or
Finnish Meteorological Institute             [e-mail]
                                    Phone  : [phone]
Possessed by a Spirit               G3 Fax : [phone]

------------------------------

Date: 12 Aug 91 10:29:22 GMT
From:
 noao!asuvax!ukma!psuvax1!wupost!cs.utexas.edu!cse!convex![e-mail]
 (William Rosenkranz)
Subject: Puting a pixel to screen
To: [e-mail]

In article <[e-mail]>
 [e-mail] (Kimmo Lahtinen) writes:
>I want to know what is now the "official" way to put a pixel to screen.
>I have read form this group that Line-A is not a good idea, but I did
>not find any simple pixel routines from VDI.

first off, line A was such an easy way to do things like this without
writing a GEM program. rue the day that atari took this away...

here is one way:

        first, find screen size (width and height) by some means. call
        these scrn_w and scrn_h. assume the pixel we want to set is
        (x,y) where (0,0) is upper left, x,y get larger positive values
        toward the lower right, up to (scrn_w-1,scrn_h-1).

        char *pscrn;    /* ptr to physical screen mem */
        char *pbyte;    /* ptr to byte containing pixel (bit) to twiddle */
        int shft;       /* amount to shift mask */

        pscrn = Physbase ();                            /* get screen loc */
        pbyte = (char *) ( (long) pscrn +               /* start here */
                           (long) y * (long)scrn_w/8L + /* goto line */
                           (long) x / 8L );             /* and byte */
        shft  = 8 - (x - (x/8)*8);                      /* setup mask */

        *pbyte |= (char) (1 << shft);                   /* to set pixel */

        *pbyte &= (char)

i hope i have this right. i just did this today for mgif (eliminating
the use of line A totally). it works. if not, this is close...

this makes no use of line A (obviously). it only requires that u know the
width of the screen. it assumes the screen width is evenly divisible by
8 (a reasonable assumption, i would think - it should be divisible by 16).
note that pscrn need not be Physbase. it could be any virtual screen
stored in memory.

this *should* be 100% portable, regardless of ST, STe, TT, etc. note that
this is for a monochrome screen!!!! doing this for color is left as an
exercise for the reader. it is not that bad, u just have to account for
interleaving of the planes when getting the byte. then again, u have to
deal with the color, i suppose.

>I hope it is not too slow.

well, this can be optimized. i did it this way for clarity (i hope).
it should be about as fast as line A would do it, give or take. i notice
no real difference in speed. you can use word offsets instead. just make
sure u get the pointer correct (remember: once u cast to long, u loose
pointer arithmetic so adding 1 is adding 1 byte, not 1 word).

note that it is easy to draw vertical or horizontal lines this way, but
a bit more complicated to draw arbitrary lines. i think i posted ages
ago a program called bez which is my (manual) screen saver. it does this
trick with bezier curves. i did not write it originally, i just ported
it. the origin escapes me but it was in a magazine (byte?) a couple of
years ago...

-bill
[e-mail]

--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: [e-mail]

------------------------------

Date: 11 Aug 91 13:24:39 GMT
From: mcsun!news.funet.fi!funic!nic.funet.fi![e-mail] (Kimmo
 Lahtinen)
Subject: Puting a pixel to screen
To: [e-mail]

Thank you for your reply, but I am afraid that it is no use for me, as
I have a high resolution graphics card. And if I am correct you routine
writes directly to screen memory, but you can not write to screen memory
of the graphics card.

Actualy you could but you have to use different system with every different
graphics card.

So I am looking for a general solution using normal system routines.
--
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Kimmo Lahtinen                      E-Mail : [e-mail] or
Finnish Meteorological Institute             [e-mail]
                                    Phone  : [phone]
Possessed by a Spirit               G3 Fax : [phone]

------------------------------

Date: 9 Aug 91 21:38:10 GMT
From: psinntp!uupsi!tfd!afp!gna!linn![e-mail] (Franck Arnaud)
Subject: Spectre GCR
To: [e-mail]

In a message of <31 Jul 91  13:48:49>, [e-mail]
writes:

 >> Do you have the little INIT that causes your menus to act like GEM
 >> menus? You know, to drop down, instead of having to be laboriously

AutoMenu does this very well. It is recent and compatible with System 7.

--- /* Point of no return; */ - Paris
    [e-mail]

------------------------------

Date: 12 Aug 91 03:24:02 GMT
From: comp.vuw.ac.nz!actrix![e-mail] (Roger Sheppard)
Subject: Turbo St
To: [e-mail]

Can any one tell me if Turbo St by Softrek is still around,
if so what is the latest Version..

If so where do I get it. No 800 No's Please..
they are no good here in NZ...

If not is Quick ST far better...???
--
***  Roger W. Sheppard             [e-mail]  ***
***  85 Donovan Rd           *     GEnie.  R.SHEPPARD5               ***
***  Kapiti                *  *    At least I don't Flicker,         ***
***  New Zealand..          *      not like a dying light globe      ***

------------------------------

Date: 12 Aug 91 03:06:27 GMT
From: comp.vuw.ac.nz!actrix![e-mail] (Roger Sheppard)
Subject: Using a big hard disk
To: [e-mail]

In article <[e-mail]> [e-mail]
 (Stephen Jacobs) writes:
> I got an impossibly great deal on a ST-4702N (600 MB Wren-V).  I have it
> hooked up to my BMS-200, and it responds to commands alright.  I can
> even get the BMS disk initializer to prepare 60 MB of useful file space on
> it.  But I want to set this thing up as a large number of large partitions,
> and to do that I need HDX.  So far, with a few reasonable tries, HDX refuses
> to do ANYTHING with this disk.  Any suggestions?
>                                          Steve   [e-mail]

Well HDX is now upto Version 4.01, but that is for the 'TT',
the old one should be Version 3.02..

You will need to write the settings for that drive into the Wincap
file, get a text reader "Tempas" and have a look at the Wincap file,
from the info in the Wincap file and the info you have on your drive
you should be possible to create your own entry to the Wincap file,
for that drive.
--
***  Roger W. Sheppard             [e-mail]  ***
***  85 Donovan Rd           *     GEnie.  R.SHEPPARD5               ***
***  Kapiti                *  *    At least I don't Flicker,         ***
***  New Zealand..          *      not like a dying light globe      ***

------------------------------

Date: 12 Aug 91 03:59:24 GMT
From: noao!ncar!midway!machine!chinet![e-mail] (Stephen Jacobs)
Subject: Using a big hard disk
To: [e-mail]

In article <[e-mail]> [e-mail] (Roy Bixler)
 writes:
>In article <[e-mail]> [e-mail]
 (Gregory Carter) writes:
>>In article <[e-mail]> [e-mail]
 (Stephen Jacobs) writes:
>>>I got an impossibly great deal on a ST-4702N (600 MB Wren-V).  I have it
>>>hooked up to my BMS-200, and it responds to commands alright.  I can
>>>even get the BMS disk initializer to prepare 60 MB of useful file space on
>>>it.  But I want to set this thing up as a large number of large partitions,
>>>and to do that I need HDX.  So far, with a few reasonable tries, HDX refuses
>>>to do ANYTHING with this disk.  Any suggestions?
>  I would recommend calling Berkeley Microsystems.  I had a
>similar problem when I first got my HD/BMS-200 combination and they
>were very helpful.

I actually called Berkeley Microsystems before buying the disk, and they gave
me a few suggestions.  I can now use all 600 MB of it using their "if all
else fails" method (partition using their fourpart partitioner).  The version
of Atari's HDX I'm using is recent enough that it asks whether the drive is
on the SCSI or the ACSI bus.  I've tried all sorts of plausible WINCAP entries,
and HDX absolutely always says it can't partition the disk until it's
formatted correctly, and it can't format the disk.

I guess, since AHDI drives the disk ok, what I really need now is a way to
define the last partition on the disk as an 'XGM' partition, and to parcel
it out.  Something that leaves the first 3 partitions alone wouldn't hurt, but
isn't necessary either.
                                    Steve

------------------------------

Date: 12 Aug 91 08:56:43 GMT
From:
 noao!asuvax!ukma!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-
 state.edu!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!fauern!faui43.infor
 matik.uni-erlangen.de!csbrod@ (Claus Brod)
Subject: Using a big hard disk
To: [e-mail]

[e-mail] (Stephen Jacobs) writes:

>I actually called Berkeley Microsystems before buying the disk, and they gave
>me a few suggestions.  I can now use all 600 MB of it using their "if all
>else fails" method (partition using their fourpart partitioner).  The version
>of Atari's HDX I'm using is recent enough that it asks whether the drive is
>on the SCSI or the ACSI bus.  I've tried all sorts of plausible WINCAP entries,
>and HDX absolutely always says it can't partition the disk until it's
>formatted correctly, and it can't format the disk.

Try HDX 4.01, not 4.00. It is much better at recognizing and formatting
SCSI disks of all kinds. Try switching off the MODE SENSE part during the
formatting process (there is a field for this purpose in the WINCAP file).

---
----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,                  Things. Take. Time.
D-8772 Marktheidenfeld, Germany                 (Piet Hein)
[e-mail]
[e-mail]
----------------------------------------------------------------------

------------------------------

End of Info-Atari16 Digest
******************************